Insecurity Against Selective-Opening Attacks: Some Key Ideas Selected Paper: Standard Security Does Not Imply Security Against Selective Opening by Bellare, Dowsley, Waters, and Yilek

Many of the standard notions of security we have examined quarter with respect to two-party communication may fail to capture notions of security in unusual settings. One such setting, not unrealistic in multi-party protocols, is the setting in which a receiver receives n individual messages from n distinct senders, all of which are encrypted and committed to their values. At some point, the receiver may pick a subset of the messages to be opened, e.g., have their contents decrypted and verified, before the protocol continues. An adversary may perform what is known as a selectiveopening attack (SOA) to corrupt this subset of messages, obtaining both the messages it contains and the random parameters (hereafeter referred to as coins) used to encrypt the messages. The authors demonstrate that an adversary who obtains both the messages and coins is able to, with high advantage, produce an output which it would not be able to replicate without receiving the coins. Concisely phrased, standard security does not imply security against selective-opening. Security against selective-opening attacks can be misleadingly thought of in terms of the following question: “If an adversary obtains the plaintexts and coins of some subset of messages, are the remaining messages still secure?” In the attack presented, the adversary does not satisfy a relation that explicitly reveals information about the un-opened messages; however, the adversary is still able to accomplish something it was unable to without accessing the coins. This highlights the strength of SOA-secure schemes that the authors provided after writing this paper, presented in class by Robert. A wide variety of encryption schemes leak the coins used for encryption. The authors provide an ElGammal-based example. Other examples include using RSA with OAEP, or CBC-mode with a prepended IV. The commonality of such schemes highlights the reality of SOA-insecurity, and the necessity for the authors’ SOA-secure schemes.